4장. AI 시스템 평가하기
AI 시스템 평가는 도메인 특화 능력·생성 능력·지시 수행 능력·비용/지연 시간이라는 네 기준으로 시작한다. 공개 벤치마크는 나쁜 모델을 걸러내는 출발점이지만 데이터 오염과 편향된 집계 때문에 맹신할 수 없다. 신뢰할 수 있는 평가는 결국 애플리케이션 고유의 기준과 파이프라인을 자체 구축해야 완성된다.
출처: Chip Huyen, 『AI 엔지니어링』 (한국어판), 4장 (pp.200~257)
학습 목표
이 장을 끝내면 다음을 할 수 있다.
- AI 시스템을 도메인 특화 능력, 생성 능력, 지시 수행 능력, 비용·지연 시간의 네 기준으로 체계적으로 평가한다
- 국소적 사실 일관성과 전역적 사실 일관성의 차이를 구분하고 각 기준에 맞는 검증 방법을 선택한다
- SelfCheckGPT·SAFE·텍스트 함의(NLI) 등 환각 탐지 기법의 작동 원리와 비용-정확도 트레이드오프를 설명한다
- 공개 벤치마크의 구조적 한계(데이터 오염·집계 편향·벤치마크 포화)를 분석하고, n-gram·퍼플렉시티 기반 오염 탐지 방법을 비교한다
- 자체 평가 파이프라인의 3단계 설계 방법(구성 요소 평가→가이드라인 수립→방법/데이터 정의)을 적용한다
- 슬라이스 기반 평가로 모델의 숨은 편향과 심슨의 역설을 탐지하고, 비즈니스 지표와 평가 지표를 연결한다
전체 흐름도
이 장의 핵심은 "무엇을 기준으로 평가하고, 어떤 순서로 모델을 고르는가"다.
[ 평가 목적 정의 ]
| 평가 주도 개발 — 개발 전 측정 기준 먼저 확정
v
[ 4가지 평가 기준 ]
|
+-- (1) 도메인 특화 능력 (MCQ 벤치마크, BIRD SQL 등)
+-- (2) 생성 능력 (사실 일관성, 안전성)
| +-- 국소적 일관성 <- 컨텍스트 기준 (요약·챗봇·비즈니스 분석)
| +-- 전역적 일관성 <- 공개 지식 기준 (일반 챗봇·팩트체크)
+-- (3) 지시 수행 능력 (IFEval, INFOBench, 역할 연기)
+-- (4) 비용·지연 시간 (TTFT, 토큰당 비용, 파레토 최적)
|
v
[ 모델 선택 — 4단계 순환 ]
| 1) 하드 속성 필터 (라이선스·개인정보·온디바이스 요구)
| 2) 공개 벤치마크로 후보군 압축 (맞춤형 리더보드 구성)
| 3) 자체 평가 파이프라인으로 최적 모델 확정
| 4) 운영 환경 지속 모니터링 + 사용자 피드백
v
[ 자체 평가 파이프라인 설계 — 3단계 ]
| 1단계: 시스템 구성 요소별 독립 평가 (턴 기반 + 작업 기반)
| 2단계: 평가 가이드라인 작성 (점수 척도·기준표·비즈니스 매핑)
| 3단계: 기준마다 적합한 방법 + 데이터 규모 결정
v
[ 파이프라인 품질 검증 ]
| 재현성 확인 / 지표 간 상관관계 점검
+-- 슬라이스 기반 평가 -> 편향·심슨의 역설 탐지
핵심 긴장: "공개 벤치마크 1위 != 내 애플리케이션 최적"
-> 데이터 오염·집계 편향·도메인 불일치가 원인
0. 사전 필수 용어
참고 — 이 장은 3장에서 소개한 자동 평가 방법(AI 평가자·참조 기반 지표·퍼플렉시티)을 전제로, 그 방법들을 실제 애플리케이션 평가에 어떻게 적용하는지를 다룬다.
- 평가 주도 개발(Evaluation-Driven Development) — 애플리케이션을 만들기 전에 평가 기준을 먼저 정의하는 방식. 소프트웨어 공학의 테스트 주도 개발(TDD)에서 영감을 받았다. 측정 가능한 목표가 있어야 투자 대비 효과를 확인할 수 있다.
- 사실 일관성(Factual Consistency) — 모델 출력이 주어진 컨텍스트(국소적) 또는 공개된 지식(전역적)과 얼마나 일치하는지를 나타내는 지표. 환각 탐지의 핵심 기준이다. 사실 비일관성(actual inconsistency)은 치명적 결과를 초래하므로 가장 많은 탐지 기법이 개발됐다.
- 데이터 오염(Data Contamination) — 모델이 평가에 사용되는 벤치마크 데이터로 학습했을 때 발생하는 문제. 실제 능력이 아닌 암기로 높은 점수를 받을 수 있어 벤치마크 신뢰도를 낮춘다. n-gram 중복(정확도 높음, 비용 큼)과 퍼플렉시티(정확도 낮음, 비용 적음) 두 방법으로 탐지한다.
- 슬라이스 기반 평가(Slice-Based Evaluation) — 전체 평가 세트를 유료/무료 사용자, 짧은/긴 입력, 특정 주제 등 하위 집합으로 나눠 각각의 성능을 독립적으로 측정하는 방법. 집계된 성능이 감추는 문제를 드러낸다.
- 심슨의 역설(Simpson's Paradox) — 집계 데이터에서는 모델 A가 모델 B보다 좋아 보이지만, 모든 개별 하위 집합에서는 모델 B가 모델 A보다 우수한 역설적 현상. 슬라이스 기반 평가가 필요한 핵심 이유다.
- 하드 속성 vs 소프트 속성 — 하드 속성은 변경 불가능한 모델 특성(라이선스, 학습 데이터, 모델 크기, 개인정보 보호 정책). 소프트 속성은 프롬프트 조정·파인튜닝 등으로 개선 가능한 특성(정확도, 유해성, 사실 일관성).
- 텍스트 함의(Textual Entailment / NLI) — 두 진술 간 관계를 함의(entailment)·모순(contradiction)·중립(neutral)으로 분류하는 NLP 과제. 사실 일관성 검증을 구조화된 분류 작업으로 바꿀 수 있다.
1. 왜 평가가 AI 도입의 가장 큰 장애물인가
배포되지 않은 애플리케이션과, 배포는 됐지만 제대로 작동하는지 알 수 없는 애플리케이션 중 어느 쪽이 더 나쁜가? 이 질문에 대부분의 현장 엔지니어는 "평가할 수 없는 쪽이 더 나쁘다"고 답한다. 평가할 수 없으면 유지보수 비용이 쌓이고, 나중에 애플리케이션을 중단하려 해도 더 많은 비용이 든다. 중고차 가격 예측 모델을 배포한 지 1년이 지나도록 예측의 정확도를 전혀 알 수 없었다는 현장 사례처럼, 이런 상황은 의외로 흔하다. 챗GPT 열풍 때 급하게 배포된 고객 지원 챗봇이 사용자 경험에 도움이 되는지 아닌지조차 확인 못하는 기업들도 많다.
평가 주도 개발 — 측정 가능한 것만 고르는 함정. 현명한 비즈니스 결정은 유행이 아닌 투자 수익률을 기준으로 한다. 추천 시스템은 구매 전환율로, 사기 탐지 시스템은 예방한 사기 금액으로, 코딩 도구는 기능적 정확성으로 성공을 측정할 수 있기 때문에 널리 채택됐다. 그러나 평가하기 쉬운 것만 개발하는 것은 가로등 아래에서 잃어버린 열쇠를 찾는 것과 같다. 측정이 어렵다는 이유로 잠재력 있는 애플리케이션을 놓칠 수 있다. 신뢰할 수 있는 평가 파이프라인을 구축할 수 있다면 훨씬 많은 새로운 애플리케이션이 가능해진다.
저자는 평가가 AI 도입의 가장 큰 걸림돌이자 기회라고 단언한다. 평가 파이프라인이 있어야 신규 애플리케이션 개발이 가능해지고, 없으면 애플리케이션이 배포됐어도 유지보수가 통제 불가 상태가 된다.
2. 도메인 특화 능력 평가
코딩과 효율성. 라틴어-영어 번역 애플리케이션을 만들려면 라틴어를 본 적 없는 모델은 쓸 수 없다. 이처럼 모델이 해당 영역의 능력을 갖추고 있는지 확인하는 것이 도메인 특화 능력 평가의 핵심이다. 코딩 능력은 기능적 정확성으로 평가하지만, 이것만으론 부족하다. 잘 달리지만 연료를 지나치게 소비하는 자동차처럼, Text-to-SQL 모델이 정확한 쿼리를 생성해도 실행 시간이 너무 길거나 메모리를 과도하게 사용한다면 실용적이지 않다.
BIRD SQL 벤치마크는 SQL 정확성과 함께 실제 실행 시간 비교를 통해 효율성도 평가한다. 코드 가독성 평가는 명확한 자동 지표가 없어서 AI 평가자 같은 주관적 방법에 의존해야 할 수 있다. 정확성과 효율성이 자동 검증 가능한 것과 대조적이다.
객관식 문제(MCQ)의 강점과 한계. 2024년 4월 기준 EleutherAI의 lm-evaluation-harness에 있는 작업의 75%가 객관식이다. 객관식은 만들기 쉽고, 검증이 간단하며, 무작위 베이스라인(4지선다는 25%)과 비교하기 쉽다. 분류는 객관식의 특별한 경우로, 트윗 감성 분류처럼 모든 문제에서 같은 선택지를 사용한다. 분류 지표로는 정확도 외에 F1 점수, 정밀도, 재현율이 있다.
그러나 객관식은 지식과 추론을 평가하기에 적합하지만, 요약·번역·글쓰기 같은 생성 능력을 평가하기에는 구조적으로 맞지 않는다. 또한 같은 문제와 선택지를 조금만 다르게 표현해도 모델의 답이 바뀔 수 있다는 프롬프트 민감도 문제가 있다. 알자라니 등의 연구(2024)는 추가 공백이나 '선택지:' 같은 지시 구문을 넣으면 모델이 답을 바꿀 수 있음을 보여줬다.
3. 생성 능력 평가 — 사실 일관성과 안전성
NLG의 역사와 현재. 자연어 생성(NLG) 분야의 연구자들은 수십 년간 개방형 출력의 품질을 평가해 왔다. 초기 지표인 유창성(문법적으로 자연스러운가)과 일관성(논리적 구조를 따르는가)은 언어 모델의 생성 품질이 크게 향상되면서 중요성이 낮아졌다. GPT-2가 2019년에 큰 화제를 모은 이유도 이전 어떤 모델보다 훨씬 유창하고 일관성 있는 텍스트를 생성할 수 있었기 때문이다. 그러나 유창성·일관성은 성능이 떨어지는 모델이나 창의적 글쓰기, 저자원 언어 애플리케이션에서는 여전히 유용하다.
대신 파운데이션 모델 시대에는 사실 일관성과 안전성이 더 핵심 기준이 됐다. 저자가 AI 기반 글쓰기 도우미를 개발할 때는 '논쟁성(controversiality)'도 관심 지표였다. 친근함·긍정성·창의성·간결성 같은 다른 지표도 있지만, 이 장에서는 사실 일관성과 안전성에 집중한다.
국소적 vs 전역적 사실 일관성. 사실 일관성은 두 가지 방식으로 검증한다.
- 국소적 사실 일관성 — 출력을 명시적으로 제공된 컨텍스트와 비교한다. 요약문이 원문을 그대로 반영하는지, 챗봇 응답이 회사 정책에 부합하는지, 비즈니스 분석 인사이트가 데이터와 맞는지가 여기에 해당한다.
- 전역적 사실 일관성 — 출력을 공개된 지식과 비교한다. 일반 챗봇, 사실 확인, 시장 조사 등 광범위한 작업에서 중요하다.
사실 일관성 검증에서 가장 어려운 부분은 주로 무엇이 사실인지 판단하는 것 자체다. "메시는 세계 최고의 축구 선수다", "아침은 하루 중 가장 중요한 식사다" 같은 진술은 어떤 출처를 신뢰하는지에 따라 사실 여부가 달라진다. 인터넷은 허위 마케팅, 정치적 의도로 조작된 통계, 선정적이고 편향된 소셜 미디어 게시물 같은 잘못된 정보로 넘쳐난다. 또한 증거 부재의 오류에 빠지기 쉽다. X와 Y의 연관성을 뒷받침하는 증거를 찾지 못했다는 이유만으로 "X와 Y 사이에 연관성이 없다"를 사실로 받아들일 수 있다.
흥미로운 연구 과제: 완(Wan) 등의 연구(2024)는 기존 모델들이 과학적 참고 문헌 존재 여부나 중립적 어조 같이 사람이 중요하게 생각하는 문체적 특징을 거의 고려하지 않고 웹사이트와 질의의 관련성에만 지나치게 의존한다고 주장했다.
환각이 자주 발생하는 패턴. 저자의 실제 프로젝트 경험에 따르면 모델은 다음 두 유형의 질의에서 환각을 더 자주 일으킨다:
- 최소한의 학습 데이터를 가진 주제 — IMO(국제수학올림피아드)보다 VMO(베트남수학올림피아드) 관련 질의에서 환각 가능성이 더 높다. IMO보다 훨씬 덜 알려진 주제이기 때문이다.
- 존재하지 않는 정보를 묻는 질의 — "X가 Y에 대해 뭐라고 말했나요?"를 물었을 때, X가 Y에 대해 언급한 적이 없는 경우 언급한 경우보다 환각 가능성이 더 높다.
벤치마크를 설계할 때 이런 패턴을 집중적으로 다루는 것이 중요하다.
AI 평가자 기반 사실 일관성 측정. 리우 등의 연구(2023)와 루오 등의 연구(2023)는 GPT-3.5와 GPT-4가 사실 일관성 측정에서 기존 방법보다 더 뛰어난 성능을 보인다는 것을 입증했다. TruthfulQA 논문에서 소개된 파인튜닝된 GPT-judge는 사람이 진실이라고 판단하는 진술을 90~96% 정확도로 예측할 수 있다.
환각 탐지 기법.
잘못된 예: 사실 일관성을 AI 평가자 하나로만 검증하고 비용 절감 방법을 고려하지 않는다.
올바른 예: 전체 데이터 100%에는 저렴한 NLI 분류기를, 1%에만 비싼 AI 평가자를 적용해 비용과 품질을 동시에 관리한다.
-
자체 검증(SelfCheckGPT) — Manakul 등(2023) 제안. 모델이 서로 일치하지 않는 여러 출력을 생성한다면 원래 출력이 환각일 가능성이 높다는 원리를 활용한다. 평가할 응답 R이 주어지면, N개의 새로운 응답을 생성하고, R이 이 N개와 얼마나 일치하는지 측정한다. 효과적이지만 응답 평가에 많은 AI 질의가 필요하므로 비용이 많이 든다.
-
지식 강화 검증(SAFE) — 구글 딥마인드가 'Long-Form Factuality in Large Language Models' 논문에서 소개한 검색 증강 사실성 평가기(Search-Augmented Factuality Evaluator). 4단계로 작동한다:
- AI 모델로 응답을 개별 문장으로 분리한다.
- 각 문장이 독립적으로 이해될 수 있도록 수정한다. 예: "20세기에 개장했다"의 주어를 원래 주어로 바꾼다.
- 각 문장에 대해 구글 검색 API에 보낼 사실 확인 질의를 제안한다.
-
AI로 문장이 검색 결과와 일치하는지(함의/모순/중립) 판단한다.
-
텍스트 함의(NLI) — 전제(컨텍스트)가 주어지면 가설(출력 또는 출력의 일부)이 함의·모순·중립 중 어디에 속하는지 결정한다. 예: '메리는 모든 과일을 좋아한다'는 전제에서 '메리는 사과를 좋아한다'는 함의, '메리는 오렌지를 싫어한다'는 모순, '메리는 닭고기를 좋아한다'는 중립이다. DeBERTa v3-base-mnli-fever-anli는 764,000개의 주석이 달린 (가설, 전제) 쌍으로 학습된 1억 8,400만 파라미터 모델로, 이 분류 작업을 수행한다.
사실 일관성 벤치마크 — TruthfulQA. TruthfulQA(Lin et al., 2022)는 사람이 잘못된 믿음이나 오해로 인해 부정확하게 응답할 수 있는 817개 질의로 구성된다. 건강, 법률, 금융, 정치 등 38개 분야를 다룬다. GPT-judge라는 파인튜닝된 AI 평가자와 함께 제공되어 자동 평가가 가능하다. 비교를 위한 사람 전문가 베이스라인은 94%다.
안전성 분류. 모델이 생성할 수 있는 위험한 콘텐츠는 다음과 같이 분류된다: 1. 욕설과 노골적인 내용을 포함한 부적절한 언어 2. '은행 강도 단계별 가이드'처럼 유해한 추천과 지침 3. 인종차별·성차별·동성애 혐오 등 혐오 발언 4. 위협과 자세한 묘사를 포함한 폭력 5. "간호사는 항상 여성 이름, CEO는 남성 이름"처럼 성별·직업 고정관념 6. 정치적·종교적 편향성 — 여러 연구에서 모델이 학습 데이터에 따라 정치적 편향성이 주입될 수 있음을 보여줬다. GPT-4는 자유주의적 성향이 강한 반면 라마는 더 권위주의적 성향을 보인다.
범용 AI 평가자도 활용할 수 있지만, 특수 목적 유해성 분류기(메타의 혐오 발언 감지 모델, 스콜코보 연구소의 유해성 분류기, Perspective API 등)는 훨씬 작고, 빠르며, 비용도 적다. 언어별 특화 모델(덴마크어, 베트남어 등)도 존재한다. RealToxicityPrompts는 10만 개의 유해 출력 유도 프롬프트를 포함하는 벤치마크다.
RAG 시스템에서의 사실 일관성. RAG(검색 증강 생성) 시스템에서 사실 일관성은 특히 중요한 평가 기준이다. 생성된 응답이 검색된 컨텍스트와 사실 일관성이 있어야 하며, 이는 6장의 핵심 주제다.
4. 지시 수행 능력 평가
지시 수행이란 무엇인가. 도메인 능력과 지시 수행 능력은 구분해야 한다. 모델이 트윗 감성을 이해하는 능력은 있지만 NEGATIVE/POSITIVE/NEUTRAL이라는 지시를 따르지 않고 HAPPY/ANGRY를 출력한다면, 지시 수행 능력이 부족한 것이다. 지시 수행 능력은 JSON 형식 출력, 길이 제한, 특정 키워드 포함/미포함 등 구조화된 요구사항을 포함하지만, "4글자 이하 단어만 사용하라"처럼 구조화되지 않은 제약도 포함한다.
InstructGPT는 지시를 따르도록 파인튜닝되었기 때문에 그 이름이 됐다. 더 강력한 모델은 일반적으로 지시를 더 잘 따른다. 예를 들어 어린이 독서 스타트업 Ello는 제한된 단어 풀로 이야기를 생성하는 시스템을 만들기 위해, 제한된 단어만 사용하라는 지시를 따를 수 있는 모델이 필요하다.
모델의 성능은 지시의 품질에 따라 달라지므로, 나쁜 출력이 모델의 문제인지 지시의 문제인지 구분하기 어렵다. 자신만의 활용 사례에 맞는 지시를 포함한 맞춤형 벤치마크를 만드는 것이 중요하다.
IFEval — 자동 검증 가능한 지시. 구글의 IFEval(지시 수행 평가)은 자동으로 검증 가능한 25가지 유형의 지시를 정의한다. 키워드 포함·빈도, 금지 단어, 글자 수, 문단 수, JSON 형식, 섹션 수, 불릿 개수, 제목 형식, 추신 포함 등이 포함된다. 이런 지시들은 프로그램으로 정확히 검증할 수 있다. 모델에게 'ephemeral'이라는 단어를 사용해 문장을 쓰라고 하면, 출력에 그 단어가 있는지 프로그램으로 확인하면 된다.
INFOBench — 의미적 지시까지 포괄. INFOBench는 형식 지시뿐 아니라 "기후 변화만 논의하라", "빅토리아 시대 영어를 사용하라", "존중하는 어조를 사용하라" 같은 내용 제약·언어 지침·문체 규칙도 평가한다. 이런 지시는 자동 검증이 어려워, 각 지시마다 예/아니오로 답할 수 있는 기준 목록을 만들어 사람이나 AI 평가자가 판단하게 한다.
예: "호텔 손님이 호텔 리뷰를 작성하는 데 도움이 되는 설문지를 만들라"는 지시에 대한 출력은 (1) 생성된 텍스트가 설문지인가, (2) 호텔 손님을 위해 설계됐는가, (3) 리뷰 작성에 도움이 되는가 — 세 기준으로 검증한다. INFOBench 연구자들은 GPT-4가 합리적으로 신뢰할 수 있고 비용 효율적인 평가자이며, 사람 전문가만큼 정확하지는 않지만 아마존 메커니컬 터크 평가자보다는 더 정확하다는 것을 발견했다.
역할 연기 평가. LMSYS의 백만 대화 데이터셋 분석에 따르면 역할 연기는 여덟 번째로 많은 활용 사례(5.83%)다. 역할 연기 능력은 두 가지로 평가한다: 1. 말투 — 출력이 해당 역할의 화법을 잘 반영하는가 2. 지식 — 해당 역할이 알 법한 내용에 기반하여 생성되는가
역할 연기 AI는 역할이 모르는 것도 모르게 해야 한다. NPC가 실수로 플레이어에게 스포일러를 하는 상황이 대표적인 실패 사례다. RoleLLM과 CharacterEval 등 벤치마크가 있으며, AI 평가자에게 역할마다 다른 프롬프트가 필요하다.
5. 비용과 지연 시간 평가
지연 시간 지표. 파운데이션 모델의 지연 시간 지표는 첫 토큰까지 걸리는 시간(TTFT), 토큰당 시간, 토큰 간 시간, 질의당 총 시간 등 여러 가지다. 자기회귀 언어 모델은 토큰을 하나씩 생성하므로 생성해야 할 토큰이 많을수록 전체 지연 시간이 길어진다. 지연 시간은 기반 모델뿐 아니라 각 프롬프트와 샘플링 변수에도 영향을 받는다. 모델에게 간단히 답하라고 지시하거나 생성 중단 조건을 설정하는 등 신중한 프롬프트 작성으로 지연 시간을 조절할 수 있다.
지연 시간을 기준으로 모델을 평가할 때는 반드시 필요한 것과 있으면 좋은 것을 구분하는 것이 중요하다. 사용자에게 더 낮은 지연 시간을 원하는지 물어보면 아니라고 할 사람은 없겠지만, 긴 지연 시간은 대개 불편한 정도일 뿐 사용을 포기할 정도로 심각한 문제는 아니다.
비용 구조 — API vs 자체 호스팅. 모델 API는 토큰 단위로 요금이 부과되어 규모가 커져도 토큰당 비용은 크게 변하지 않는다. 자체 호스팅은 규모가 커질수록 토큰당 비용을 크게 줄일 수 있다. 하루 최대 10억 토큰 처리 가능한 클러스터를 이미 구축했다면, 하루 100만 토큰이든 10억 토큰이든 컴퓨팅 비용은 같다. 따라서 기업은 트래픽 규모에 따라 API 사용과 자체 호스팅 사이에서 결정해야 한다. 많은 모델이 70억 개나 650억 개의 파라미터를 가진 것은 GPU 메모리 구성(16GB, 24GB, 48GB, 80GB)을 최대한 활용하도록 설계됐기 때문이다.
파레토 최적화. 여러 목표(품질, 지연 시간, 비용)를 동시에 최적화하는 것을 파레토 최적화라고 한다. 타협할 수 없는 요구사항을 먼저 정한 다음(예: 지연 시간 200ms 이내), 해당 요구사항을 충족하지 못하는 모델을 제외하고, 남은 모델 중 가장 좋은 것을 선택하는 방식이 효과적이다.
6. 모델 선택 과정
하드 속성 vs 소프트 속성. 모델 선택 시 변경 불가능한 하드 속성(라이선스, 학습 데이터, 모델 크기, 개인정보 보호 정책)과 개선 가능한 소프트 속성(정확도, 유해성, 사실 일관성)을 구별해야 한다. 처음 몇 개의 프롬프트에서 정확도가 20%였다가 작업을 두 단계로 나누자 70%까지 급상승한 경험처럼, 소프트 속성은 생각보다 크게 개선될 수도 있다. 반면 몇 주를 조정해도 사용 불가 수준에 머무르는 경우도 있다. 하드 속성과 소프트 속성의 경계는 상황에 따라 달라진다. 직접 최적화할 수 있다면 지연 시간은 소프트 속성이지만, 다른 사람이 호스팅하는 모델을 사용한다면 이는 하드 속성이 된다.
모델 평가 4단계 프로세스. 모델 선택은 일반적으로 네 단계를 순환한다: 1. 하드 속성이 맞지 않는 모델 제외 2. 공개 벤치마크와 리더보드로 유망한 후보군 압축 3. 자체 평가 파이프라인으로 최적 모델 찾기 4. 운영 환경에서 지속적 모니터링
이 과정은 선형이 아니라 순환적이다. 후반 단계에서 얻은 정보로 이전 단계의 결정을 변경할 수 있다. 예: 처음에는 오픈 소스 모델 호스팅을 원했지만, 공개·비공개 평가 후에 원하는 수준의 성능을 달성할 수 없다는 것을 깨닫고 상업용 API로 전환할 수 있다.
오픈 소스 모델 vs 모델 API — 7가지 고려 사항.
| 고려 사항 | 모델 API | 자체 호스팅 |
|---|---|---|
| 데이터 프라이버시 | 데이터를 외부에 전송 (삼성 챗GPT 유출 사례) | 외부 전송 불필요 |
| 데이터 계보·저작권 | 계약으로 위험 일부 방어 | 학습 데이터 투명성 낮음 |
| 성능 | 독점 모델이 우세 | 오픈 소스 격차 좁혀지는 중 (MMLU 기준) |
| 기능성 | 확장·함수 호출·구조화 출력 지원 / 로그프롭 제한 | 로그프롭·파인튜닝·양자화 자유도 |
| 비용 | API 비용 (토큰당) | 엔지니어링 비용 (규모 커지면 절약) |
| 제어·투명성 | 모델 변경 불투명, 접근 권한 상실 위험 | 모델 동결 가능, 변경사항 확인 용이 |
| 온디바이스 | 인터넷 필요 | 기기에서 직접 실행 가능 |
오픈 소스 모델이 독점 모델을 따라잡기 어려운 구조적 이유: 가장 경쟁력 있는 모델을 가진 기업은 보통 그것을 API 뒤에 숨겨두고 더 약한 모델만 오픈 소스로 공개한다. 또한 오픈 소스 개발자들은 사용자 피드백을 충분히 받아 모델을 개선하기도 어렵다.
a16z의 2024년 연구에 따르면 기업들이 오픈 소스 모델에 관심 갖는 두 가지 주요 이유는 제어(37%)와 커스터마이징 가능성(37%)이며, 비용(26%)이 그 뒤를 따른다.
오픈 소스 모델 라이선스 주의사항: 메타의 라마 2·3는 월간 활성 사용자 7억 명 이상인 경우 메타의 특별 라이선스가 필요하다. 현재(2025년 8월 기준) 라마 라이선스는 모델 출력을 다른 모델 개선에 사용하는 것을 허용하지 않는다. 구글의 젬마와 미스트랄-7B는 아파치 2.0으로 출시됐다.
7. 공개 벤치마크와 데이터 오염
공개 리더보드의 한계. 허깅페이스의 오픈 LLM 리더보드는 처음에 4개, 나중에 6개의 벤치마크(ARC-C, MMLU, HellaSwag, TruthfulQA, WinoGrande, GSM-8K)로 모델 순위를 매겼다. 같은 시기 스탠퍼드 HELM 리더보드는 10개 벤치마크를 사용했는데, 허깅페이스와 겹치는 것은 MMLU와 GSM-8K 두 개뿐이었다. 서로 다른 리더보드가 다른 벤치마크를 사용하면 모델 순위를 비교하거나 해석하기 어렵다.
벤치마크 간 상관관계. 2024년 1월 계산된 허깅페이스 리더보드 6개 벤치마크 간 피어슨 상관계수를 보면, WinoGrande·MMLU·ARC-C는 모두 추론 능력을 평가하므로 서로 강한 상관관계를 보인다(WinoGrande-MMLU: 0.9011). TruthfulQA는 다른 벤치마크들과 중간 정도의 상관관계만 보인다(ARC-C: 0.4809). 모델의 추론·수학 능력이 좋다고 해서 진실성까지 같이 좋아지지는 않는다는 뜻이다. 상관관계가 높은 벤치마크들을 함께 사용하면 집계 결과가 실제보다 편향되게 나타날 수 있다. 허깅페이스는 단순 평균을, HELM은 평균 승률을 집계 방식으로 사용한다.
벤치마크 포화와 업데이트. 허깅페이스는 2024년 6월 리더보드를 마지막으로 개편한 지 1년도 지나지 않아 완전히 새로운 벤치마크 세트로 교체했다. GSM-8K는 MATH Lvl 5로, MMLU는 MMLU-PRO로 대체됐다. GPQA(대학원 수준 질의응답), MuSR(다단계 추론), BBH(추론), IFEval(지시 수행)이 추가됐다. 불과 몇 년 만에 벤치마크가 초등학교 수준에서 대학원 수준으로 올라가야 했다는 사실이 AI 발전 속도를 보여준다.
HELM은 컴퓨팅 비용이 많이 드는 벤치마크를 제외하기도 한다. 스탠퍼드는 HELM 테스트로 30개 모델을 평가하는 데 약 8만~10만 달러를 썼다.
데이터 오염 — 구조적 문제. 데이터 오염(data contamination)은 모델이 평가 벤치마크 데이터로 학습했을 때 발생한다. 스탠퍼드 박사과정 학생 라이런 섀퍼는 풍자 논문 'Pretraining on the Test Set Is All You Need'(2023)에서 벤치마크 데이터만으로 학습시킨 100만 파라미터 모델이 훨씬 큰 모델들보다 높은 점수를 받았음을 보여줬다.
데이터 오염이 일어나는 방식: - 의도적 오염 — 높은 점수를 얻으려고 벤치마크 데이터로 의도적으로 학습 - 비의도적 오염 — 인터넷에서 수집한 데이터에 공개 벤치마크가 실수로 포함됨 - 간접 오염 — 학습 데이터와 평가 데이터가 동일한 출처(예: 같은 수학 교과서)에서 온 경우 - 선의의 오염 — 고품질 벤치마크 데이터가 모델 성능 향상에 도움이 되므로, 사용자 공개 전에 벤치마크 데이터로 계속 학습시키는 경우
오픈AI는 GPT-3의 학습 데이터에 주요 벤치마크가 40% 이상 포함된 경우가 13개나 된다는 것을 발견했다(Brown et al., 2020). 이것이 기존 벤치마크가 빠르게 포화 상태가 되는 이유 중 하나다.
오염 탐지 방법: - n-gram 중복 — 평가 샘플의 특정 토큰 시퀀스가 학습 데이터에도 있으면 오염된 것으로 간주. 정확도가 높지만 전체 학습 데이터와 비교해야 하므로 시간과 비용이 많이 소모되며, 학습 데이터 접근이 불가능하면 사용 불가. - 퍼플렉시티 — 모델이 평가 데이터에 대해 퍼플렉시티가 유난히 낮다면 학습 과정에서 이미 접했을 가능성이 높다. 정확도는 낮지만 훨씬 적은 자원으로 가능.
허깅페이스 등 리더보드 주최측은 이상치를 감지하기 위해 특정 벤치마크에 대한 모델들의 성능 표준편차를 그래프로 나타낸다. 공개 벤치마크는 데이터 일부를 비공개로 유지하고 모델 개발자들이 자동으로 평가할 수 있는 도구를 제공해야 한다.
공개 벤치마크는 나쁜 모델을 걸러내는 출발점으로 유용하지만, 애플리케이션에 가장 적합한 모델을 찾아주지는 않는다. 공개 벤치마크로 후보군을 압축한 뒤 반드시 자체 평가 파이프라인을 실행해야 한다.
8. 평가 파이프라인 설계 — 3단계
1단계: 시스템의 모든 구성 요소 평가
이력서 PDF에서 현재 직장을 추출하는 애플리케이션을 예로 들면, 두 단계(PDF→텍스트 변환, 텍스트→현재 직장 추출)를 각각 독립적으로 평가해야 한다. 전체 출력만 보면 어느 단계에서 실패하는지 알 수 없기 때문이다.
평가는 두 수준에서 이루어진다: - 턴 기반 평가(turn-based evaluation) — 각 출력물의 품질을 평가한다. - 작업 기반 평가(task-based evaluation) — 시스템이 최종 작업을 완료했는가, 몇 번의 대화가 필요했는가를 평가한다. 시스템이 문제를 2번 만에 해결하는 것과 20번 만에 해결하는 것은 큰 차이가 있다.
사용자들이 가장 중요하게 생각하는 것은 과제 완수 능력이므로 작업 기반 평가가 더 중요하다. 그러나 작업 간 경계를 구분하기 어려울 때가 많다. BIG-bench의 'twenty questions' 벤치마크는 스무고개 게임을 활용한 작업 기반 평가의 좋은 예시다.
2단계: 평가 가이드라인 만들기
링크드인은 생성형 AI 애플리케이션 배포 1년을 돌아보며 첫 번째 장애물이 평가 가이드라인을 만드는 것이었다고 공유했다. 정확한 응답이 항상 좋은 응답은 아니다. AI 기반 직무 평가 애플리케이션에서 "당신은 이 자리에 전혀 맞지 않습니다"는 정확할 수 있지만 좋지 않은 응답이다. 좋은 응답은 직무 요구사항과 지원자의 배경 사이 간극을 설명하고, 지원자가 이 간극을 좁히기 위해 무엇을 할 수 있는지 알려줘야 한다.
랭체인의 2023년 AI 현황에 따르면, 사용자들은 애플리케이션 평가에 평균 2.3개의 다른 유형의 피드백(기준)을 사용했다.
각 기준에 대해 이진법(0/1), 1~5점 척도, 삼분법(-1/0/1) 중 하나를 선택하고, 예시와 기준표를 만들어야 한다. 기준표를 동료·친구 등과 함께 검증하고, 모호함을 없애기 위해 계속 다듬어야 한다. 이 가이드라인은 8장의 파인튜닝용 지시 데이터 주석 작업에도 재사용될 수 있다.
평가 지표를 비즈니스 지표와 연결하기. 예를 들어 고객 지원 챗봇의 사실 일관성 80%는 비즈니스에 어떤 의미인가? 이상적으로는 다음처럼 매핑한다: - 사실 일관성 80%: 고객 지원 요청의 30% 자동화 가능 - 사실 일관성 90%: 50% 자동화 가능 - 사실 일관성 98%: 90% 자동화 가능
이렇게 매핑하면 특정 지표를 개선하는 데 자원을 투자할 때 더 확신을 가질 수 있다. 또한 고착도(DAU·WAU·MAU)나 참여 지표(대화 수, 방문 기간)처럼 비즈니스 목표를 먼저 이해하고, 그것을 AI 평가 지표와 연결하는 것이 중요하다.
3단계: 평가 방법과 데이터 정의
유해성 감지에는 특화된 분류기, 관련성 측정에는 의미적 유사도, 사실 일관성에는 AI 평가자를 사용하는 식으로 기준마다 다른 방법을 적용한다. 동일한 기준에 여러 방법을 혼합할 수도 있다: 전체 데이터 100%에 대해 저렴한 분류기로 낮은 품질의 신호를, 1%에 대해 비싼 AI 평가자로 고품질 신호를 제공하는 방식이다.
로그프롭을 사용할 수 있다면 사용하는 게 좋다. 세 가지 클래스에 대한 로그프롭이 모두 30~40% 사이라면 모델이 이 예측에 확신이 없다는 뜻이고, 한 클래스에 대해 95%라면 매우 확신한다는 뜻이다. 상용 모델 제공업체는 다른 사람이 로그프롭으로 자사 모델을 복제하지 못하도록 대부분 로그프롭을 공개하지 않거나 제한적으로만 공개한다.
운영 환경에서도 사람 평가에 의존하는 것을 두려워하지 말자. 링크드인은 AI 시스템과의 일일 최대 500개 대화를 수동으로 평가하는 프로세스를 개발했다.
평가 데이터 규모. 오픈AI의 추정에 따르면, 한 시스템이 더 나은지 95% 신뢰도로 확인하기 위해 필요한 평가 샘플 수:
| 감지할 차이 | 95% 신뢰도에 필요한 표본 크기 |
|---|---|
| 30% | ~100개 |
| 10% | ~1,000개 |
| 3% | ~10,000개 |
점수 차이가 3배 줄면 필요한 샘플 수는 10배 증가한다. EleutherAI의 lm-evaluation-harness 벤치마크의 예시 중앙값은 1,000개, 평균은 2,159개다.
9. 평가 파이프라인 자체 평가와 슬라이스 기반 접근
평가 파이프라인의 품질 점검. 평가 파이프라인 자체도 평가해야 한다. 다음 질문들로 확인한다: - 더 나은 응답이 실제로 더 높은 점수를 받는가? - 같은 파이프라인을 두 번 실행하면 같은 결과가 나오는가? (AI 평가자는 온도를 0으로 설정해 재현성을 높여야 한다) - 지표 간 상관관계는 어떠한가? 두 지표가 높은 상관관계를 보이면 하나는 불필요하다. 반면 번역과 수학 벤치마크 간 상관관계가 없다면 번역 능력 향상이 수학 능력에 영향을 미치지 않는다고 추론할 수 있다. - 평가 파이프라인이 애플리케이션에 얼마나 많은 비용과 지연 시간을 추가하는가? 일부 팀은 지연 시간을 줄이기 위해 평가를 생략하기로 결정한다. 이는 위험한 도박이다.
부트스트랩 검증: 100개 예시로 구성된 평가 세트가 신뢰할 만한지 알아보려면, 원래 100개에서 복원 추출로 100개를 반복 샘플링하여 평가 결과를 비교한다. 한 부트스트랩에서 90%, 다른 부트스트랩에서 70%가 나온다면 파이프라인이 신뢰할 만하지 않다.
슬라이스 기반 평가의 목적. 데이터를 하위 집합으로 나누어 각각의 성능을 개별적으로 살펴보는 이유는 네 가지다: 1. 편향 축소 — 소수 사용자 그룹에 대한 편향을 발견한다 2. 디버깅 — 특정 하위 집합에서 성능이 나쁜 이유(길이, 주제, 형식)를 찾는다 3. 개선 영역 발굴 — 긴 입력에 성능이 나쁘다면 다른 처리 기술을 시도할 수 있다 4. 심슨의 역설 회피 — 집계된 성능이 감추는 반전 현상을 탐지한다
심슨의 역설 예시: 모델 A는 그룹1에서 93%, 그룹2에서 73%, 전체 78%를 달성한다. 모델 B는 그룹1에서 87%, 그룹2에서 69%, 전체 83%를 달성한다. 전체 집계에서는 모델 B(83%)가 모델 A(78%)보다 좋지만, 각 하위 그룹에서는 모델 A가 모델 B보다 좋다.
데이터는 등급(유료/무료 사용자), 트래픽 출처(모바일/웹), 입력 길이, 오타 포함 여부 등으로 슬라이스할 수 있다. 범위 외(out-of-scope) 입력에 대한 평가 세트도 마련해야 한다.
반복적 개선과 실험 추적. 요구사항과 사용자 행동이 변화하면서 평가 기준도 진화한다. 반복이 필요하지만, 평가 프로세스가 계속 변경된다면 평가 결과를 개발 지침으로 사용할 수 없다. 평가 데이터, 기준표, AI 평가자에 사용된 프롬프트 및 샘플링 구성 등 모든 변수를 실험 기록으로 남겨야 한다.
핵심 개념 정리
| 개념 | 한 줄 요약 |
|---|---|
| 평가 주도 개발 | 애플리케이션 개발 전 평가 기준 먼저 정의 — TDD의 AI 버전 |
| 도메인 특화 능력 | 모델이 필요한 지식을 갖추고 있는가 — 학습 데이터에 없으면 불가 |
| 객관식 벤치마크 | 지식·추론 평가에 적합, 생성 능력 평가에는 구조적으로 부적합 |
| 국소적 사실 일관성 | 명시된 컨텍스트 기준 — 요약·챗봇·비즈니스 분석에 중요 |
| 전역적 사실 일관성 | 공개된 지식 기준 — 일반 챗봇·사실 확인에 중요 |
| SelfCheckGPT | 자체 검증: 여러 출력이 불일치 → 환각 가능성 높음 (비용 큼) |
| SAFE | 지식 검증: 검색 엔진으로 개별 사실 4단계 검증 (구글 딥마인드) |
| 텍스트 함의(NLI) | 함의·모순·중립으로 분류 — 사실 일관성을 분류 작업으로 전환 |
| 하드 vs 소프트 속성 | 하드=변경 불가(라이선스·데이터), 소프트=개선 가능(정확도·유해성) |
| 데이터 오염 | 벤치마크 데이터로 학습 시 점수 과장 — n-gram·퍼플렉시티로 탐지 |
| 벤치마크 포화 | 모델 성능 향상으로 기존 벤치마크가 변별력 잃는 현상 |
| 심슨의 역설 | 집계에서 A>B이지만 모든 하위 집합에서 B>A인 역설 |
| 슬라이스 기반 평가 | 하위 집합별 성능 독립 측정 — 편향·역설·디버깅에 필수 |
| 작업 기반 평가 | 턴별 품질이 아닌 최종 과제 완수 여부 + 대화 횟수 평가 |
| 파레토 최적화 | 품질·지연시간·비용 간 트레이드오프에서 최적 균형점 찾기 |
| 평가 지표-비즈니스 지표 연결 | 사실 일관성 80% = 고객 지원 30% 자동화 등으로 매핑 |
실무 체크리스트
- [ ] 애플리케이션을 만들기 전에 네 가지 평가 기준(도메인·생성·지시·비용)을 정의했는가?
- [ ] 코딩 평가에 기능적 정확성뿐 아니라 실행 효율성과 코드 가독성도 포함했는가?
- [ ] 사실 일관성 검증에 국소적(컨텍스트 기반)과 전역적(공개 지식 기반) 두 가지를 구분했는가?
- [ ] 환각이 자주 발생하는 질의 패턴(최소 지식 주제, 존재하지 않는 발언 질의)을 벤치마크에 포함했는가?
- [ ] SelfCheckGPT·SAFE·NLI 중 비용과 정확도 요구사항에 맞는 방법을 선택했는가?
- [ ] 공개 벤치마크를 후보군 압축에만 사용하고, 최종 선택은 자체 평가 파이프라인으로 했는가?
- [ ] 사용하는 공개 벤치마크의 데이터 오염 가능성을 n-gram 또는 퍼플렉시티로 확인했는가?
- [ ] 벤치마크 간 상관관계를 확인하여 중복된 능력을 중복 집계하지 않았는가?
- [ ] 평가 지표를 비즈니스 지표(자동화율, 전환율 등)와 매핑했는가?
- [ ] 시스템의 각 구성 요소를 독립적으로 평가하는 구조를 갖췄는가?
- [ ] 턴 기반 평가와 작업 기반 평가를 모두 수행했는가?
- [ ] 평가 데이터를 슬라이스하여 심슨의 역설과 편향을 확인했는가?
- [ ] 평가 파이프라인의 재현성(같은 입력 → 같은 결과)을 부트스트랩으로 검증했는가?
- [ ] AI 평가자의 온도를 0으로 설정하여 일관성을 높였는가?
- [ ] 모델 API와 자체 호스팅의 장단점을 데이터 프라이버시·비용·제어·온디바이스 관점에서 분석했는가?
- [ ] 로그프롭이 필요한 경우(분류·퍼플렉시티 평가)를 고려하여 모델/API를 선택했는가?
연습문제
- 개념. 국소적 사실 일관성과 전역적 사실 일관성의 차이를 정의하고, 각각이 중요한 실제 애플리케이션 사례를 하나씩 들어라. 또한 각 경우에 적합한 환각 탐지 기법을 하나씩 추천하라.
- 분석. 객관식 벤치마크가 언어 모델 평가에 널리 사용되는 이유 세 가지와, 그것이 적합하지 않은 평가 영역, 그리고 프롬프트 민감도 문제를 설명하라.
- 설계. 법률 계약서 요약 챗봇을 만든다고 할 때, 평가 기준 네 가지를 도출하고, 각 기준에 적합한 평가 방법(AI 평가자, 특화 분류기, 함수 기반 검증 등)을 선택하라. 비용 최적화 방법도 포함하라.
- 비판적 사고. 공개 리더보드에서 1위를 차지한 모델이 자신의 애플리케이션에 최적이 아닐 수 있는 이유를 데이터 오염, 벤치마크 선정, 집계 방식, 심슨의 역설 관점에서 설명하라.
- 적용. 고객 지원 챗봇의 사실 일관성이 80%일 때 이를 98%로 높이면 비즈니스적으로 어떤 의미가 생기는지 설명하고, 이 개선을 위해 평가 파이프라인에서 먼저 확인해야 할 사항을 슬라이스 기반 평가 관점에서 순서대로 나열하라.
최신 동향 (2026-05 기준)
최신 동향 (검증 2026-05-21) — AI 시스템 평가 원칙은 책 내용이 유효하다. 최근 고난도 벤치마크(GPQA Diamond·FrontierMath)와 사실성 평가(SimpleQA)가 표준 참고로 추가됐으니 함께 보라. 벤치마크 포화 속도가 빨라지면서 동적으로 생성되는 평가 데이터셋과 라이브 평가 방식이 주목받고 있다.
부록 A. 용어 사전
| 한글 | 영문 | 의미 |
|---|---|---|
| 평가 주도 개발 | Evaluation-Driven Development | 개발 전 평가 기준을 먼저 정의하는 방식. TDD의 AI 버전 |
| 사실 일관성 | Factual Consistency | 모델 출력이 컨텍스트(국소) 또는 공개 지식(전역)과 일치하는 정도 |
| 사실 비일관성 | Factual Inconsistency | 치명적 결과를 초래할 수 있는 환각 — 별도로 측정하고 탐지 필요 |
| 자체 검증 | SelfCheckGPT | 동일 질의에 여러 출력을 생성해 불일치가 크면 환각으로 판단하는 기법 |
| 검색 증강 사실성 평가기 | SAFE (Search-Augmented Factuality Evaluator) | 4단계: 분리→수정→검색→판단으로 개별 사실을 검증하는 구글 딥마인드 기법 |
| 텍스트 함의 | Textual Entailment / NLI | 전제-가설 간 관계를 함의·모순·중립으로 분류하는 NLP 과제 |
| 데이터 오염 | Data Contamination | 평가 벤치마크 데이터로 학습해 암기로 점수를 높이는 현상 |
| 벤치마크 포화 | Benchmark Saturation | 모델 성능 향상으로 기존 벤치마크가 변별력을 잃는 현상 |
| 슬라이스 기반 평가 | Slice-Based Evaluation | 전체 데이터를 하위 집합으로 나눠 각각의 성능을 독립적으로 측정하는 방법 |
| 심슨의 역설 | Simpson's Paradox | 집계 데이터에서는 A>B이지만 모든 하위 집합에서는 B>A인 역설적 현상 |
| 하드 속성 | Hard Attribute | 변경 불가능한 모델 특성 (라이선스, 학습 데이터, 개인정보 보호 정책) |
| 소프트 속성 | Soft Attribute | 프롬프트 조정·파인튜닝 등으로 개선 가능한 모델 특성 (정확도, 유해성) |
| 파레토 최적화 | Pareto Optimization | 품질·지연 시간·비용 등 여러 목표 간 트레이드오프에서 최적 균형점을 찾는 방법 |
| 첫 토큰까지 걸리는 시간 | Time to First Token (TTFT) | 요청 후 모델이 첫 번째 토큰을 출력하기까지의 지연 시간 |
| 턴 기반 평가 | Turn-Based Evaluation | 각 출력물의 품질을 독립적으로 평가하는 방식 |
| 작업 기반 평가 | Task-Based Evaluation | 최종 과제 완수 여부와 대화 횟수를 기준으로 평가하는 방식 |
| 오픈 웨이트 | Open Weight | 가중치는 공개됐지만 학습 데이터는 비공개인 모델 |
부록 B. 핵심 비교표
공개 벤치마크 vs 자체 평가 파이프라인
| 구분 | 공개 벤치마크 | 자체 평가 파이프라인 |
|---|---|---|
| 용도 | 나쁜 모델 걸러내기 (후보군 압축) | 내 애플리케이션에 최적 모델 확정 |
| 한계 | 데이터 오염, 편향된 집계, 도메인 불일치, 빠른 포화 | 구축 비용·시간 필요 |
| 예시 | MMLU, GSM-8K, IFEval, TruthfulQA, GPQA | 슬라이스 평가, 비즈니스 지표 매핑 |
| 결론 | 출발점으로만 사용 | 최종 결정 근거 |
환각 탐지 기법 비교
| 방법 | 원리 | 비용 | 정확도 | 적합한 경우 |
|---|---|---|---|---|
| AI 평가자 (일반) | 프롬프트로 판단 요청 | 중간 | 높음 | 컨텍스트 있는 경우 |
| SelfCheckGPT | 여러 출력 간 일관성 | 높음 (N번 추론) | 높음 | 전역 사실 일관성 |
| SAFE | 검색 엔진 기반 4단계 | 높음 | 높음 | 전역 사실 확인 |
| NLI 분류기 | 함의·모순·중립 분류 | 낮음 | 중간 | 국소 사실 일관성, 대규모 적용 |
| 로그프롭 | 예측 확신도 측정 | 매우 낮음 | 간접적 | 분류·퍼플렉시티 평가 |
잘못된 예 / 올바른 예 — 모델 선택 순서
잘못된 예: 공개 리더보드 1위 모델을 바로 운영 배포 → 도메인 불일치·오염 점수·상관 편향으로 실패 가능
올바른 예: 하드 속성 필터 → 공개 벤치마크 후보 압축 → 자체 파이프라인 검증 → 운영 모니터링 순서 준수
잘못된 예 / 올바른 예 — 데이터 오염 대응
잘못된 예: 벤치마크 점수를 그대로 신뢰하고 데이터 오염 여부를 확인하지 않음
올바른 예: n-gram 중복(학습 데이터 접근 가능 시) 또는 퍼플렉시티(접근 불가 시)로 오염 가능성을 먼저 점검하고 자체 평가로 보완
부록 C. 추천 참고 자료
검증된 외부 자료 (Tier 1 공식, 생존 확인 2026-05-21)
| 자료 | 링크 |
|---|---|
| Hugging Face 오픈 LLM 리더보드 | huggingface.co/spaces/open-llm-leaderboard |
| EleutherAI lm-evaluation-harness | github.com/EleutherAI/lm-evaluation-harness |
| 자료 | 설명 |
|---|---|
| 책 3장 | 자동 평가 방법 (AI 평가자, 참조 기반 지표, 퍼플렉시티) 상세 내용 |
| 책 5장 | 프롬프트 엔지니어링과 프롬프트 민감도 대응 방법 |
| 책 6장 | RAG 시스템의 검색 및 에이전트 평가, 사실 일관성 측정 |
| 책 7장·9장 | 모델의 메모리 사용량, 지연 시간, 비용 계산 |
| 책 8장 | 데이터셋 엔지니어링, AI 생성 데이터, 주석 가이드라인 재활용 |
| 책 10장 | 운영 환경에서 사용자 피드백 수집과 온라인 평가 |
| TruthfulQA (Lin et al., 2022) | 사실 일관성 벤치마크 원본 논문 — 817개 오해 유발 질의, 38개 분야 |
| SelfCheckGPT (Manakul et al., 2023) | 자체 검증 기반 환각 탐지 원본 논문 |
| SAFE (Wei et al., 2024) | 검색 증강 사실성 평가기 — 구글 딥마인드 개발, 4단계 검증 |
| IFEval (Zhou et al., 2023) | 자동 검증 가능한 25가지 지시 수행 능력 평가 벤치마크 |
| Chip Huyen, 『머신러닝 시스템 설계』 | 슬라이스 기반 평가 상세 내용, 심슨의 역설 예시 |
| BIRD SQL 벤치마크 | SQL 정확성 + 실행 효율성 동시 평가 |
부록 D. 연습문제 풀이
-
(국소적 = 명시된 컨텍스트 기준, 전역적 = 공개 지식 기준) 국소적 사실 일관성은 모델 출력을 명시적으로 제공된 컨텍스트와 비교한다. 예를 들어 계약서 요약문이 원문을 그대로 반영하는지, 기업 챗봇 응답이 회사 정책에 부합하는지가 해당한다. 적합한 탐지 기법은 NLI(텍스트 함의) 분류기다. 국소적 컨텍스트를 전제로 삼고 모델 출력을 가설로 삼아 함의·모순·중립을 분류하면 된다. 전역적 사실 일관성은 출력을 공개된 지식과 비교하며, 일반 챗봇이나 팩트체크 서비스에서 중요하다. 인터넷에 허위 마케팅·정치적 조작 정보가 혼재하므로 무엇이 사실인지 판단 자체가 어렵다. 적합한 기법은 SelfCheckGPT(여러 출력 간 불일치 탐지)나 SAFE(검색 엔진 기반 4단계 검증)다.
-
(객관식 장점 세 가지: 제작 용이, 자동 검증, 무작위 베이스라인 비교 — 부적합 영역: 생성 능력 — 프롬프트 민감도) 객관식 벤치마크가 널리 사용되는 이유는 첫째 만들기 쉽고, 둘째 정답 여부를 프로그램으로 자동 검증할 수 있으며, 셋째 4지선다라면 25%라는 무작위 베이스라인과 비교하기 쉽기 때문이다. 반면 객관식은 지식과 추론을 평가하기에 적합하지만, 요약·번역·글쓰기처럼 열린 형태의 생성 능력을 평가하기에는 구조적으로 맞지 않는다. 생성 능력은 좋은 응답을 만드는 것이지, 좋은 응답을 고르는 것이 아니기 때문이다. 또한 문제와 선택지를 조금만 다르게 표현해도(추가 공백, '선택지:' 구문 삽입 등) 모델의 답이 바뀌는 프롬프트 민감도 문제가 있어 평가 결과의 신뢰도를 낮출 수 있다.
-
(법률 계약서 요약 챗봇 평가 기준 네 가지 도출 및 방법 선택)
| 평가 기준 | 구체적 요구사항 | 적합한 방법 | 비용 최적화 |
|---|---|---|---|
| 도메인 특화 능력 | 법률 용어·계약 구조 이해 | 법률 MCQ 벤치마크, 자체 법률 문제 세트 | 공개 법률 벤치마크 선활용 |
| 생성 능력 — 국소적 사실 일관성 | 요약이 원문 계약서와 불일치하지 않는지 | NLI 분류기 (100%), AI 평가자 (1%) | 저렴한 NLI로 대량 처리, 비싼 AI 평가자는 1%만 |
| 지시 수행 능력 | JSON 형식 출력, 조항 번호 포함, 길이 제한 | IFEval 방식의 함수 기반 검증 | 자동화 가능하므로 추가 비용 낮음 |
| 비용·지연 시간 | 계약서 한 건 처리 시간 및 토큰당 비용 | TTFT·총 쿼리 시간 측정, 파레토 최적화 | 지연 시간 임계치 설정 후 초과 모델 제외 |
-
(공개 리더보드 1위 != 내 애플리케이션 최적) 첫째, 데이터 오염 때문이다. 모델이 평가 벤치마크 데이터로 학습했다면 실제 능력이 아닌 암기로 높은 점수를 받을 수 있으며, 오픈AI는 GPT-3 학습 데이터에 주요 벤치마크가 40% 이상 포함된 경우가 13개나 된다고 밝혔다. 둘째, 벤치마크 선정의 문제다. 허깅페이스와 스탠퍼드 HELM 리더보드는 서로 다른 벤치마크를 사용하며 겹치는 항목은 두 개뿐이어서, 어느 리더보드 기준인지에 따라 같은 모델의 순위가 달라진다. 셋째, 집계 방식의 편향이다. ARC-C·MMLU·WinoGrande처럼 상관관계가 높은 벤치마크(MMLU-WinoGrande 상관계수 0.9011)를 단순 평균하면 추론 능력이 과대 반영되고 사실 일관성(TruthfulQA 상관계수 0.45~0.55)이 과소 반영된다. 넷째, 심슨의 역설이다. 전체 집계에서 1위인 모델이 내 애플리케이션의 핵심 슬라이스(예: 전문 법률 쿼리)에서는 더 나쁠 수 있다. 결국 공개 벤치마크는 나쁜 모델을 걸러내는 출발점일 뿐이며, 최종 선택은 자체 평가 파이프라인으로 확정해야 한다.
-
(사실 일관성 80% → 98% 개선의 비즈니스 의미와 파이프라인 확인 순서) 사실 일관성이 80%라는 것은 응답 10건 중 2건이 허위 또는 컨텍스트와 불일치하는 정보를 포함한다는 뜻이다. 책의 예시처럼 "사실 일관성 80% = 고객 지원 요청의 30% 자동화, 98% = 90% 자동화"로 비즈니스 지표와 매핑하면 투자 결정에 더 확신을 가질 수 있다. 파이프라인에서 먼저 확인할 사항 순서: (1) 시스템 구성 요소별 독립 평가 — PDF 추출 단계인지 생성 단계인지 어느 단계에서 오류가 발생하는지 격리한다. (2) 슬라이스 기반 평가 — 특정 주제(결제 관련 vs 일반 문의), 입력 길이(짧은 vs 긴 질의), 사용자 유형(유료 vs 무료) 슬라이스에서 특히 낮은 일관성이 나타나는지 확인하여 개선 우선순위를 정한다. (3) 평가 파이프라인 재현성 확인 — AI 평가자 온도를 0으로 설정하고 동일 입력에 동일 결과가 나오는지 부트스트랩으로 검증한 뒤 개선 실험 결과를 신뢰할 수 있게 비교한다.
클릭하거나 Space를 눌러 뒤집기